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ABSTRACT 


Every year the Department of Defense (DoD) spends between 24 and 32 billion 
dollars on software alone, with maintenance costs comprising the majority of this figure. 
Recent studies have indicated that an effective solution to help curtail development and 
maintenance costs is to capture the rationale behind systems requirements and designs, and 
use this information throughout the life cycle. This thesis explores the use of REMAP/MM 
and multimedia based design rationale management systems. Based on a case study, a 
detailed example illustrating to use REMAP/MM in various systems development activities 
is presented. 



I. INTRODUCTION 


The software budget for the DoD is becoming a larger part of the entire budget each year. 
Currently it is estimated that DoD is spending between 24 billion and 32 billion dollars on 
software costs alone (USAGAO, 1992), accounting for between 8 and 11 percent of the entire 
DoD budget. However the amount of money the DoD spends on software does not tell the whole 
story. The DoD, like most software dependent companies, these days, is quickly approaching the 
"maintenance wall". As budgets tighten, the maintenance costs of installed systems are using up 
the available resources, significantly affecting new systems development (Sprague and 
McNurlin, 1993). During the 1970s, maintenance of software accounted for between 35 and 40 
percent of the software budget for an information system organization. This number jumped to 
approximately 60 percent during the 1980s. It is estimated that maintenance costs today comprise 
70 to 80 percent of the DoD software budget. As a result, DoD, as well as many companies, are 
seeking a major shift in the way they build and maintain software in order to drive maintenance 
costs down. (Pressman, 1992) 

A. THE DESIGN RATIONALE SOLUTION 

Recent research suggests that in large scale computer systems, the capture and use of the 
design rationale can significantly improve software development and maintenance productivity 
(Ramesh and Dhar, 1992). Design rationale serves multiple purposes: definition of unstated 
assumptions, clarification of dependencies among artifacts, decision constraints, and justification 
or validation of design decisions (Gruber and Russell, 1992). The effective capture and use of 
this design rationale should be considered a vital part of the design process. 



B. WHY RATIONALE? 


Over half of the cost of development of complex computer-based information systems 
can be attributed to decisions made in the requirements and design phases of the software 
development process (Walz et al, 1993). Understanding system requirements and design 
rationale during the later stages of the development life cycle can be useful in managing system 
change and can facilitate the reuse of certain components, helping to decrease software costs. 

For instance, the design of any system involves groups of people working through various phases 
of the development life cycle. Within each of the groups, every member brings individual 
viewpoints and expertise. Individual team members do not have all of the knowledge required 
for the project, and must acquire additional information before accomplishing productive work. 
Group interaction involves information exchange, communication, and the resolution of various 
issues between the team members. A primary outcome of this group interaction is design 
rationale; the foundation on which a project or system is built. 

Due to the size of most projects, development timelines can easily stretch into several 
years. During this time period, most development teams experience turnover of personnel. As 
the individuals in the group change, the dynamics of interaction between the members also 
change. Additionally, the new members of the group need to be updated on the progress of the 
project, so that they may better understand their own role within the group. Research has shown 
that a great deal of the vital information given to a team during the requirements phase of 
development is lost (Walz et al, 1993). Design decisions can become completely lost from one 
meeting to the next. Even when individuals remember that a certain decision has been made, 
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they often find it difficult to recreate the rationale behind the decision ("Why are we doing it this 

C. THE DIFFICULTY IN CAPTURING DESIGN RATIONALE. 

Capturing design rationale is a difficult and time consuming task. In particular, 
determining what aspects of design rationale are worthy of capture requires a great deal of insight 
and experience. The more complex the system, the more difficult it is to trace the decision 
process during any phase of systems development. Capture of design rationale needs to be as 
detailed, and complete as possible. The capture methods must prevent ambiguity in the raw data 
as much as possible, as well as be as unintrusive as possible. This will allow the user the 
opportunity to make his own interpretations of what the data means. (Ramesh and Sengupta, 

1994) 

D. WHY MULTIMEDIA? 

The use of multimedia in capturing design rationale provides three benefits. First, 
multimedia is particularly useful in capturing physical gestures, body language and other forms 
of constructive communication among members in the design group (Ramesh and Sengupta, 
1993). 

Second, once captured, these narratives can then be used by different individuals for 
different purposes. For example, a user interested in the reasoning behind a particular artifact 
would use the videotape of a design session quite differently from a user interested in learning 
about the points of view of the respective stakeholders. 

Finally, the unprocessed information that multimedia provides allows the user to interpret 
and assign their own evaluations of the decision process. Also, design decisions are often 



characterized by assumptions that are not stated explicitly, but must be inferred from the context 
of the discussion. A richer context for understanding the collaboration mechanisms, process and 
culture in design groups can enable the user to interpret the rationale behind the creation of 
artifacts. (Ramesh and Sengupta, 1993). 

E. RATIONALE AND MULTIMEDIA 

A model that has been successfully used to structure design rationale is the Issue Based 
Information Systems (IBIS) model (Rittel, 1973). However, informal representations of design 
rationale, such as a multimedia record, have shortcomings too. Such information can not be 
easily indexed and retrieved. Further, the potential for automated reasoning with such 
knowledge is severely restricted. Recent research suggests that a semiformal representation that 
provides a structure to the design rationale information, in addition to multimedia, would be 
appropriate for design rationale capture and use (Ramesh and Sengupta, forthcoming). 

The REMAP/MM system currently under development at the Naval Postgraduate School 
in Monterey, California, is an attempt to couple an extended IBIS model with multimedia. The 
REpresentation and MAintenance of Process knowledge (REMAP) provides a conceptual model 
and mechanism for the representation and reasoning of design rationale knowledge (Ramesh and 
Dhar, 1992). 

F. METHODOLOGY 

In this thesis, we present an example to illustrate the use of multimedia in the capture of 
design rationale during system development. The example consists of segments of design 
rationale from a system development exercise in a utility company. The example and the 
multimedia segments used in this document are based on a case study in the utility industry. 



These detailed scenarios describe the capture of design rationale in the requirements engineering, 
systems analysis, and detailed design phases of system development. 

G. LIMITATIONS 

The example is limited in that only a few snapshots of the development process have 
been captured. In order to fully document and capture all of the design rationale of a project, a 
full-fledged longitudinal study should be carried out. This example is intended to provide a 
proof of concept model, not a comprehensive design rationale record. An important issue not 
addressed in the research is the detailed evaluation of the usefulness of multimedia design 
rationale capture mechanisms. 

H. OUTLINE 

The next section provides an overview of the REMAP/MM model and system and 
introduces the example. Chapter 3 provides a detailed description of REMAP/MM use in three 
system development activities. The focus of the discussion is to illustrate the REMAP model 
and multimedia in capturing and integrating design rationale. The final chapter provides the 
conclusion and recommendation. 
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II. A REMAP/MM EXAMPLE 


A. REMAP/MM 

The objects in the REMAP model include requirements, the primitives of IBIS (issues, 
positions, arguments, assumptions), as well as decisions. Requirements represent the goals or 
objectives of the design problem. Issues are problems, concerns, or questions relating to specific 
requirements. Positions are solutions which respond to an issue. Arguments are statements that 
support or object to positions. Assumptions behind arguments are also effectively captured. 
Decisions are the result of the deliberation of issues. These relationships are illustrated in Figure 
1 below. 



Figure 1. REMAP Model. Source Ramesh and Dhar, 1992. 






REMAP/MM is a multimedia extension of the model. REMAP/MM supports the capture 


of design rationale by providing a graphical user interface for the design team to use during the 
conduct of their deliberations. It also provides a mechanism for the hyperlinking of multimedia 
objects to design rationale. For example, multimedia clips that elaborate issues, arguments, 
positions, and decisions that a design team encounters are stored in an interactive document, the 
REMAP/MM model. The user can explore the document by selecting buttons, highlighted text, 
or other objects that are linked to multimedia data such as sound clips, graphics, or even video 
clips. With such a document, the user can view issues or arguments that have been captured, and 
can follow the logic of why a decision was made. 

B. AN EXAMPLE OF REMAP/MM USE 

In the example, we consider a hypothetical software development team engaged in the 
design of complex service process ordering system for a local power and utilities company 
located in Duval County, Florida. The system will be using a centralized telephone answering 
service center that is connected to a large number of field stations via an on-line computer. The 
team includes all of the important stakeholders, such as management, engineering, and customer 
relations. The primary task of the development team is to clearly articulate the various system 
requirements with respect to each stakeholders point of view. Each stakeholder comes to the 
design team with different perspectives and requirements. For instance, the engineers are 
interested in efficiently screening service request tags to assist in determining power outage 
locations, and customer relations is concerned with being able to update clients quickly and 
effectively when service calls are received. 



The example is intended to illustrate that by using REMAP/MM during requirements 


definition, analysis, and design of the system, design rationale can be effectively captured. The 
team will be capturing a history of the project that can be accessed and examined long after the 
team members have moved on to other jobs or locations. A full understanding of the design 
rationale of the system, along with a better insight of the systems' original intent, enhances the 
ability to modify the system at a later time. 



III. IMPLEMENTATION OF THE REMAP/MM MODEL 


A. USE OF REMAP/MM IN REQUIREMENTS ENGINEERING 

During the requirements phase of a project, detailed knowledge of the background and 
history of the system is required in order to make sound decisions concerning the system's design 
requirements. For example, when a system designer is building a new user interface, s/he should 
have a deep understanding of how the interface would be used, and what the potential users will 
need to effectively perform their jobs. This portion of the example illustrates how REMAP/MM 
could be used during the requirements phase to effectively capture this essential background 
information. The following represents a hypermedia document that may be linked to the 
requirements hierarchy in REMAP. Highlighted words in the document have hyperlinks to 
multimedia segments. In this section, following a highlighted word, the section and paragraph or 
figure that is hyperlinked to that word is shown in parentheses. By navigating through such a 
document, the user can achieve a comprehensive understanding of the requirements of the 
system. 

1. Background Information 

When the power company first began providing power, its clients were located in the 
downtown Jacksonville area. As the city grew and expanded, outlying cities such as Jacksonville 
Beach, Neptune Beach, and Orange Park were incorporated into the company's power grid, 
making Jacksonville the largest geographical city in the United States. Today, the city has 
expanded to include all of Duval County, an area of nearly 840 square miles. The city has 
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experienced a population growth rate of nearly 28 percent in the past ten years, and power 
demands have increased at a similar rate. 

To improve the service to this expanding city while dealing with company-wide 
down-sizing, the power company has determined that an automated service order processing 
system is the most economical solution. This new system must provide a more efficient means 
of handling calls from the customer for maintenance and emergency service, and allow the 
company to dispatch troubleshooters in the most effective manner. 

Presently, the power company operates four regional centers. Each center consists of 3-5 
phone Service Operators (see Section A,2) who answer calls from within their service area. 
These operators provide the customer with a variety of services, arrange electrical service start or 
stop dates, answer any billing question the customer might have, as well as take any trouble call 
information from the customer and forward the information to the service dispatcher. The 
Service Dispatcher (see Section A,3) prioritizes daily work schedules, assigns jobs to field 
units, and monitors the progress of all field workers. The field workers have to coordinate there 
work with the distribution operator. The Distribution Operator (see Section A, 4) coordinates 
all field maintenance from a central location. 

The new system must allow the company to expediently dispatch their limited number of 
linesmen more effectively. When a service call comes into the center, a Multipurpose 
Customer Service Order (see Figure 10) or service tag is generated. This tag contains all 
relevant information about the customer service request. When there is a large-scale power 
outage, thousands of these tags can be generated. In order to dispatch the limited number of 
troubleshooters to the most likely source of the outage, the tags must first be manually sorted by 
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geographic area. Once these tags are sorted, they must then be cross-referenced with a power 
Grid (see Section A, 5) map according to substation and feeder lines . From this map, a more 
precise localization of where the trouble is can be determined. Since this is all performed 
manually, it can typically take several hours to localize and dispatch troubleshooters to the 
proper area. 

With the Current Switching Method (see Section A, 7), switches must be manually 
opened and tested to determine if they are indeed the trouble spot, or the problem exists 
somewhere else along the line. Once the exact location of the trouble has been determined, the 
troubleshooters can begin working on the solution to the problem. With the current system, it is 
not uncommon for 15-24 hours to pass before power can be restored. With the installation of 
the Intelligent Switches And Fuses (see Section A, 8), the power company's goal is to 
completely automate the service system. Each client's address will be linked to a particular fuse 
or switch, allowing the computer to expediently localize the trouble spot. The Intelligent 
Switches And Fuses will allow for some of the repair work to be completed remotely. The 
distribution operator needs simply to switch the intelligent switch on or off over the phone. This 
will allow for more expedient troubleshooting before having to dispatch workers to the field. 

This new system must provide a more efficient means of handling the processing of customer 
maintenance request status. Once the troubleshooters are on site, they must assess the situation 
and notify the regional center of the estimated time that will be required to fix the problem. This 
information is currently first passed to the dispatcher from the linesmen. From there it is 
forwarded to the service center operators, time permitting, where it is then posted on a 
chalkboard so the operators can inform calling customers of the estimated time until their service 
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is restored. The linesmen then coordinate with the distribution operator to ensure that they can 
safely perform the maintenance without endangering other workers or themselves. 

Finally, after the work has been completed, every person who called in must be contacted 
to determine if their power has been restored. If their power is not back on, the entire process 
must be repeated. 

2. Service Operator 

Presently, the power company operates four regional centers. Region One (see Figure 3). 
Region Two (see Figure 4). Region Three (see Figure 5). Region Four (see Figure 6). Each 
center consists of 3-5 phone operators who answer calls from within their service area. Service 
Operator Video (see Figure 2). These operators provide the customer with a variety of services, 
arrange electrical service start or stop dates, answer any billing question the customer might 
have, as well as take any trouble call information from the customer and forward the information 
to the service dispatcher. 



Figure 2. Video of Operator servicing calls. 
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Region Three 


Region Four 


North of I-10, East of 1-95 



Figure 5. Bitmap of Region Three. 


South of I-10, East of the St. Johns River 



Figure 6. Bitmap of Region Four. 
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3. Service Dispatcher 

The service dispatcher plays a vital role within the maintenance system of the power 
company. Service Dispatcher Video (see Figure 7). 



Due to the extremely large Geographic Area (see Figure 8), that the company serves, a 
great deal of coordination and prioritizing must take place to ensure that service is maintained 
and restored to as many people as possible in the shortest amount of time. In accomplishing this 
goal, the service dispatcher must prioritize daily work schedules, assign jobs to field units, and 
monitor the progress of all field workers. Additionally, during the evening hours, the service 
dispatcher becomes the only service operator on duty, increasing the amount of coordination 
required. 
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4. Distribution Operator 

The distribution operator is one of the key safety coordinators for all maintenance actions. 
When a field worker needs to perform maintenance on a particular section of line, the 
distribution operator ensures that the maintenance is performed safely. The operator does this by 
referencing a checklist of maintenance steps while the field worker is performing the 
maintenance. While doing this, s/he must also make sure that the power to the effected line is 
secured, and that it is safe for the field worker to proceed. Distribution Operator Video (see 
Figure 9). 



Figure 9. Distribution Operator Video. 
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5. Grid 

What is commonly referred to as the "grid" is in fact the layout of all the electrical lines 
throughout the city. Grid (see Figure 11) 



The power grid is made up of substations, lines, circuit breakers, switches, and fuses. 
Switches and Fuses, (see Figure 12). This grid is in turn laid over a map of the geographic area, 
allowing for isolation of individual residences or businesses that may be experiencing problems. 
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6. Switches And Fuses 
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Figure 12. Switches and Fuses. 
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Substations are the sources for the power that goes out on a particular line. The line, 
typically 21,000 volts, carries the power throughout the area for distribution. Smaller, 1000 volt 
lines feed off of the 21 kilovolt lines and step down to distribute electricity to individual 
residences and business. On each of these high and low power lines are circuit breakers, 
switches, and fuses. These devices protect the equipment from surges and underages of power, 
which can cause damage to vital equipment. 
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7. Current Switching Method 

During a global, large scale outage, workers must progressively switch on and off the 
switches within the system in order to isolate where the problem is located. Once the problem 
has been located, only then may work proceed in order to restore service. This is typically a very 
time consuming endeavor, requiring a great deal of coordination and manpower. When work or 
maintenance needs to be performed on a particular line, a field worker must go out to the circuit 
breakers, switches, or fuses directly upstream and downstream from the affected piece of 
equipment, and manually switch them off to isolate the line. Once this has been accomplished, 
then work on that line or piece of equipment may proceed. Current Switching Method Video 
(see Figure 13). 



Figure 13. Video of engineer explaining current switching method. 
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8. Intelligent Switches and Fuses 

The company has begun to replace its old technology Switches And Fuses (see Figure 


12) with new, "intelligent" switches and fuses. Intelligent Switches Video (see Figure 14). 
These new devices can be controlled via the telephone, automatically switching on or off when 
receiving the appropriate code. This will greatly reduce the required manpower to isolate 
problem spots on the grid. These switches are denoted on the power grid map with the "TC" 
code, which means telephone controlled. 


Hi'S Hi-Fi STEREO 


► I I SP 0:02: 20:: 05 


igure 14. Video of Engineer explaining intelligent fuses. 
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B. USING REMAP/MM DURING SYSTEM ANALYSIS 

The following section of the example illustrates REMAP/MM's use during the system 

analysis phase. In the scenario, the analysts are engaged in a deliberation on a requirement for 

processing service orders. (The deliberation in terms of REMAP primitives is shown in Figure 
15.) Three issues that are raised by the team members are: 

•How should calls be handled? 

•How are service orders prioritized? 

•How are service orders tracked? 

The deliberation involves verifying positions or alternatives that solve the issues and 
arguments behind them, and their underlying assumptions. We briefly describe how various 
multimedia segments of the discussion are incorporated in the design rationale knowledge. 

1. Process Service Order Information 

A primary requirement is that the system should be able to handle incoming calls, 
establish priorities among the calls, and track the calls once they have been answered. Many 
customers require up to date and accurate information in order to make important, sometimes life 
or death, decisions. For example, a residential customer may be reliant on an electrically 
operated medical device. She could not survive for more than five hours without this device. 
This customer needs to know when the power will be restored, so a decision can be made as to 
whether or not to move to a location where electricity is still available. 
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Figure 15. Process Service Order Information Overview. 

a. How Should Calls Be Handled? (Issue) 

The primary interface between the company and the customer is through service 
calls. Meeting the needs of the customer is the company's main goal, and achieving this can best 
be accomplished by effectively and efficiently handling incoming calls. The issue of importance 
here is how to handle incoming calls. 

i. Human Operator (Position) 

The first position is that the calls should all be handled by a human 
operator, who will take information and route the call manually. 

ii. Personal Interaction (Argument) 

The operator is the only person that the customer will interact with. All of 
the customer's perceptions about the company are based on their experiences with the phone 
operators. For this reason, human operators are preferable to automated systems. Computer 
systems cannot provide the personal touch that customers prefer. 
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iii. Current Answering Methods (Argument) 

The current system of call handling is operator interaction with the 
customer. An automated system would add costs to the established system, and would degrade 
the company's public image both among its employees and the general public. 

iv. Computer Routing (Position) 

Computer routing allows the customer to indicated what type of service is 
required before having to talk with an operator. 

v. Voice Mail (Argument) 

A voice mail system would allow the customer to leave a message 
indicating what type of service is required, allowing the operators to handle more urgent calls 
directly. Voice Mail Discussion (see Figure 16). 
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Figure 16. Video of voice mail discussion. 
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•’i. Time Critical Calls (Argument) 


Most calls that come in to the service center are not of a critical nature. 

By using a computer routing system that breaks out calls by their type (billing, maintenance, 
service, etc.), operators will be able to spend more time handling critical calls. 

b. How Are Service Orders Prioritized? (Issue) 

Due to company down-sizing and shrinking fiscal resources, the company must 
develop a priority scheme to better serve the customers' needs. The issue is what is the best 
method to prioritize incoming service requests? 

i. Service Type (Position) 

Calls should be prioritized by the type of service required by the customer, 
i.e., emergency service, billing service, or maintenance service. 

ii. Service Required (Argument) 

By prioritizing calls according to service type, emergency situations can 
be handled immediately, allowing for timely resolution of service problems. Less vital services 
such as billing will still be handled expediently, but when an emergency arises, appropriate 

resources can be immediate focused, possibly preventing damages and losses. 

iii. Computer Routing (Assumption) 

A computer routing system is being used to handle initial calls. 

iv. Customer Type (Position) 

Calls should be prioritized by the type of customer, either industrial or 

residential. 
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v. Specialization (Argument) 

Prioritizing under this scheme would allow the field workers to specialize 
in various areas of service. Industrial customers have needs that differ from residential 
customers. 

vi. Computer Routing (Assumption) 

A computer routing system is being used to handle initial calls. 

vii. Equipment (Argument) 

There are different material and equipment requirements for each type of 
customer. By prioritizing by customer type, this equipment may be centrally managed and 
accounted for, reducing the company's costs. 

viii. Computer Routing (Assumption) 

A computer routing system is being used to handle initial calls, 
e. How Are Service Orders Tracked? (Issue) 

The status of all service calls must be tracked and updated, to allow for timely 
customer notification. How these calls should be tracked is the issue. 

i. Current Method (Position) 

Currently, all calls are manually tracked by placing follow-up calls for 
every service tag generated. This method guarantees that all customers are given return calls 
updating them on the status of their service 

ii. Manual Tracking (Argument) 

The current method of tracking orders is satisfactory, and performs well. 
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iii. Computer Storage (Position) 

A database system of call storage should be implemented to help track 
orders. Computer Storage Video (see Figure 17). 

iv. Automated Tracking (Argument) 

The new system should store calls on a centralized database without 
actually generating the tags. When service has been restored, the computer should be able to 
automatically dial the customer back, and let the operator update the customer. This will greatly 
reduce the time demands, because the tags will not have to be manually sorted and rechecked. 



Figure 17. Video of computer storage discussion. 
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C. USING REMAP/MM IN THE DESIGN PHASE 


The following is an example use of REMAP/MM during the design phase of system 
development. During this phase, the development team is engaged in discussions concerning the 
specific design mechanisms to process service tags. The issues being considered are: 

■How to get customer records? 

■How should the service operator's screen be organized? 

•How should service tags be screen?. 

(These deliberations are shown in terms of REMAP primatives in figure 18.) These 
deliberations identify and solve issues concerning the design phase of the project. Included in 
this section are descriptions of how the multimedia segments are incorporated. 
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1. Process Service Tags 



Figure 18. Process Service Tags Overview. 


Automating the processing of the service tags should provide the company with the 

following information: 

1) Grid customer is on. 

2) Feeder Number of customer. 

3) Is this an isolated event or a global outage? 

It is required that the system show that it can provide the above information faster and 
with fewer people involved in the process. 

a. How to Get Customer Record? (Issue) 

A customers record contains a variety of information. Customer address, phone 
number, and account number are the basics. Included in the record is what grid the customer is 
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on, the feeder number, maintenance historical records, as well as all billing information. Some 
of this information is added to the newly generated tag. The issue is: How should the customers 
record be retrieved? 

i. Entire Record (Position) 

The entire record should be retrieved by the customer service operator at 
the time of the phone call. If a service tag is to be generated by the call, the appropriate 
information will be added to the tag at that time. The operator will be able to verify the 
correctness of the address as well. 



If the call is a request for billing information, it can be handled at that 
time. All of the customer's information is already there. Not all of the information need be 
displayed at all times. The operator should have the ability to "drill down" to more detailed 
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information as it is needed. Drill Down Interface Video (see Figure 19). For this reason, the 

information should be retrieved and ready to display for whatever the situation is. 

ii. Better Customer Relations (Argument) 

When a customer calls in, the call is posted on the Call Status Board. Call 
Status Board Video (see Figure 20). The operator has no idea of what the customer is calling 
about until she gathers more information. Because the operator is the main interface between the 
company and the customer, the operator should have quick and ready access to all of that 
customer's information. At any given time, the customer could be calling about a billing 
problem, a power outage, or a maintenance problem. For this reason, the operator needs to be 
able to instantly retrieve each of these types of data. The most efficient and expedient way of 

doing this is to retrieve the entire record as soon as the call is taken. 

iii. Good Public Relations (Assumption) 

Good public relations is important in this industry due to constantly 
increasing costs. The operators are the primary communicators and representatives for the 
company, and hence must be capable of handling nearly any situation that could arise over the 
phone. 

iv. Fill In Name And Address Of Customer (Position) 

If a service tag is to be generated from this call, the information for the tag 

can be obtained during the tag processing, not during the phone call. Only the name, address, 
and phone number of the customer are needed and these can be obtained by the operator at that 
time. If there is a billing problem, then just the billing information of the customer needs to be 
retrieved. 
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v. Faster Process (Argument) 

By not having to retrieve the entire customer record every time a phone 
call comes into the service operator center, more calls can be handled, providing better service to 
the customer. 



Figure 20. Video of Call Status Board. 


b. How Should The Service Operator Screen Be Organized? (Issue) 

Do the computer interfaces used by service operators need to be redesigned to 
better streamline the new automated process? Current Screen Interface Video (see Figure 21). 

i. Nine To Ten Categories For The Operator To Choose From 

(Position) 

The screen used by the service operators should have a list of 9 to 10 
categories for the operators to classify a maintenance request under. 

ii. Current Tag Setup 9-10 Categories For The Operator To Choose 

From (Argument) 

Ninety nine percent of all problems fall under these specified categories. 
The maintenance people will not use any more information than the basics anyway. This is also 
the current interface setup. No new training required. 
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iii. Operator Fill In Text (Position) 

The screen should have the basic address information for the operator to 
confirm correct. Then have a text box for the service operator to type in a description of the 
problem. This will allow for precise descriptions of the problem, reducing the troubleshooting 

time required by the field workers. 

iv. More Information (Argument) 

The more information describing the problem on the tag will help the 
maintenance people understand the problem better before actually talking to the customer 
themselves. 

v. Good Typists (Assumption) 

All the service operators are good typists, so this will not slow the process 

down any. 
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vi. One Sized Text Box (Assumptions) 

One set sized text box will be able to handle any description made by a 

customer. 

c. How Should The Service Tags Be Screened? (Issue) 

The manual screening process that is used currently is just too slow. This process 

must be automated. Each tag will have on it the customers grid number, as well as source side 
device tag number. The data base must be able to screen the tags and sound an alert if there 
seems to be a global outage occurring. 

i. Screen All Tags Generated In The Last 30 Minutes (Position) 

If a tag for a complete electrical failure is generated, it needs to be 
compared to any tag with a similar complaint to determine if this is an isolated event or not. If 
not, then there is a possibility of a global failure. One method suggested to determine this would 
be to compare the tag to those tags generated in the last 30 minutes. 


ii. Fewer Tags Generated (Argument) 

This comparison will allow fewer tags to be generated if there is a global 

outage. 

iii. Last 10 Tags (Position) 

Power failure tags need to be compared with the last 10 tags regardless of 
time in order to detect a global failure. 

iv. Easier Method (Argument) 

This is a easier method to implement and it gets the same job done. Fewer 

tags will be generated. 
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IV. RECOMMENDATIONS AND CONCLUSIONS 


As a system develops, the documentation that is produced becomes the formal 
memory of the project. What is missing from this memory is the reasoning behind the 
decision that produced the end product. This design rationale is a vital component of any 
complex design. Examining the design rationale of a complex system can lend greater 
insight and understanding to the system, and can be applied to future system upgrades or new 
projects. 

Design rationale produces numerous artifacts which, when properly captured, can 
assist future design team members in recreating complex decisions and the reasoning behind 
them. The REMAP/MM model for capturing design rationale provides a graphical interface 
for the design team to use in their deliberations. This model, through the use of hypertext 
documentation, allows the team member to quickly locate issues that have been deliberated 
over, and examine their rationale. The user will be able to use written documents, 
photographs, video clips, voice clips, or any other media for capturing the design rationale. 

REMAP/MM provides the user with the ability to seamlessly transition from a 
graphical representation of the decision process to the actual multimedia artifact that was 
captured during the deliberations of the issue. Such a facility should greatly increase the 
productivity of future designers. 

The example developed for this thesis illustrates the effective capture of a wide 
variety of artifacts, such as video, bitmaps, and sound clips. The complexity of designing a 
large scale service order processing system for a large power company can easily be 
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imagined. A system of this complexity would typically require three to five years to fully 
develop and reach implementation. The example only addresses two of the relatively small 
sub-processes of the entire system. It is beyond the scope of this work to include a 
"complete" example of design rationale for this system. However, the example is intended to 
highlight the important characteristics of a multimedia based design rationale system. A 
study of such technology would consist of a longitudinal study over the entire life cycle, 
addressing both capture and use of design rationale. 

A great deal of time and domain knowledge is required to determine what type of 
artifacts should be captured using multimedia. For instance video taping a design meeting 
often does not effectively capture all the reasoning behind certain decisions made during the 
meeting. Additionally, keeping the entire meeting on-line is currently impractical. 
Significant time and effort is required to effectively glean the vital decision process 
information from the vast amount of data that is communicated during a meeting. Although 
the example for this thesis is relatively small, hours of video and other artifacts were 
generated. This required a tremendous amount of editing and analysis to determine what 
artifacts represented useful design rationale. It is our recommendation that once a important 
decision has been made, the design rationale artifacts that led to that decision should be 
immediately documented. This would prevent the loss of important information, and allow 
for a more accurate representation of the decision process. 
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